Automated double firmware upgrade

ABSTRACT

A method of upgrading the software load of a device includes receiving a configuration file and checking if a device software load matches load information (EE) of the configuration file. If the device software load does not match the EE of the configuration file, a check is made to determine if the device software load matches new load information (NE) of the configuration file.

PRIORITY CLAIM

This application claims priority under 35 USC 119 to USA application No.61/042,467 filed on Apr. 4, 2008, which is incorporated herein byreference in its entirety. This application also claims priority under35 USC 119 to USA application No. 61/073,651 filed on Jun. 18, 2008,which is incorporated herein by reference in its entirety.

BACKGROUND

In some situations it becomes complicated to upgrade the software loads(e.g. operating software) of devices deployed in the field. In somecases, one or more interim loads must first be installed be the devices,before a final load will be accepted and installed. In prior techniquesthis has required manual action to first get the interim load(s)installed, before upgrading to the final desired load. This isparticularly a problem when customers have units in inventory which arerunning especially old loads.

One prior art solution to this problem is to manually upgrade theaffected devices to an interim load so that they can then accept thedesired load, which is specified in a configuration file which thedevices receive via a network. This requires either coordination betweeninstallers and personnel responsible for deploying the new loads, or itrequires scripts to run every night looking for devices that need toreceive an interim load. In the latter case, the installer may leave thedevice facility without being able to verify full operation of thedevice.

A prior art process for provisioning a modem or other devices with asoftware load is illustrated in FIG. 2. The process begins 202 and amodem receives a configuration file 204. This configuration file maycome from, for example, a provisioning server 104 communicating over anHFC (Hybrid Fiber Coax) network 150 facilitated by a CMTS (Cable ModemTermination System) 106. If there is software load information in theconfiguration file 206, a check is done to determine if the current loadof the device matches the load information in the configuration file208. If it does, then the process concludes. If not, an upgrade to a newload is performed 210. The device resets 212 to activate the newsoftware load, and the process concludes 214.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, the same reference numbers and acronyms identifyelements or acts with the same or similar functionality for ease ofunderstanding and convenience. To easily identify the discussion of anyparticular element or act, the most significant digit or digits in areference number refer to the figure number in which that element isfirst introduced.

FIG. 1 is a block diagram of an embodiment of an environment in whichone or more aspects of the present invention may be deployed.

A prior art process for provisioning a modem or other devices with asoftware load is illustrated in FIG. 2.

FIG. 3 is a flow chart of an embodiment of a process to provision adevice with a software load.

FIG. 4 is a flow chart of an embodiment of a process of provisioning adevice with a software load.

DETAILED DESCRIPTION

References to “one embodiment” or “an embodiment” do not necessarilyrefer to the same embodiment, although they may.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense as opposed to anexclusive or exhaustive sense; that is to say, in the sense of“including, but not limited to.” Words using the singular or pluralnumber also include the plural or singular number respectively.Additionally, the words “herein,” “above,” “below” and words of similarimport, when used in this application, refer to this application as awhole and not to any particular portions of this application. When theclaims use the word “or” in reference to a list of two or more items,that word covers all of the following interpretations of the word: anyof the items in the list, all of the items in the list and anycombination of the items in the list.

“Logic” refers to signals and/or information that may be applied toinfluence the operation of a device. Software, hardware, and firmwareare examples of logic. Hardware logic may be embodied in circuits. Ingeneral, logic may comprise combinations of software, hardware, and/orfirmware.

Those skilled in the art will appreciate that logic may be distributedthroughout one or more devices, and/or may be comprised of combinationsof instructions in memory, processing capability, circuits, and so on.Therefore, in the interest of clarity and correctness logic may notalways be distinctly illustrated in drawings of devices and systems,although it is inherently present therein.

The techniques and procedures described herein may be implemented vialogic distributed in one or more computing devices. The particulardistribution and choice of logic is a design decision that will varyaccording to implementation.

Described herein are embodiments of a process and system to provide‘double pump’ software load upgrades to a device using a singleconfiguration file. In fact, although described at times in terms of adouble upgrade process, the techniques described herein may be appliedto perform any number of intermediate and final software upgrades for adevice, not merely two.

FIG. 1 is a block diagram of an embodiment of an environment in whichone or more aspects of the present invention may be deployed. One ormore cable modems 100 are coupled via an HFC (Hybrid Fiber Coax) network150 to upstream network components. One such upstream component is aCable Modem Termination System (CMTS) 106. In practice, there may bemany CMTS devices 106 servicing many modems 100 in a typical HFC network150. HFC networks are commonly found in cable television deploymentsinvolving both optical communication components and radio frequency (RF)components.

The CMTS 106 provides data communication capability to the modems 100from and over the HFC network 115. The data communication facilityprovided by the CMTS 106 may also be employed to provision the modems100, for example, with software loads (e.g. operating software). TheCMTS 106 may coordinate with provisioning server 104 to communicate tothe modems 100 configuration and provisioning information, such assoftware load version information. The CMTS 106 may coordinate withprovisioning server 104 to communicate to the modems 100 otherprovisioning information such as DOCSIS (Data Over Cable ServiceInterface Specification) upstream and downstream channel mapping. TheCMTS 106 may further communicate with a load server 102 to communicateto the modems 100 software loads in manners in accordance with theprinciples described herein.

In one embodiment, a configuration file is provided comprisingManagement Information Base (MIB) data objects, possibly including anEnhanced Firmware Loading MIB (i.e. ‘NE). Older/existing loads softwareloads running on devices will not recognize and therefore will ignorethe Enhanced Firmware Loading MIB. These older loads will only respondto the currently defined MIB entry (the ‘load information’, i.e. ‘EE’)and will therefore upgrade to the load specified by the loadinformation. The load specified in the currently defined MIB entry willrespond to the Enhanced Firmware Loading MIB (the ‘new load information’NE). The device load installs the load specified with the loadinformation EE; this load, in turn, examines and responds to theEnhanced Firmware Loading MIB (NE) and makes an intelligent decision onwhether an additional upgrade is needed based on its current load andthe specified new load information.

One embodiment of a process in accordance with these principles isillustrated by the following ‘pseudocode’. In the following pseudocodedescription, EE (existing entry) refers to the load information that alldevices will respond to. NE (new entry) refers to the new loadinformation that only some devices (e.g. with newer loads installed)will respond to. Note that the device may comprise the logic to carryout the acts of this iterative upgrade process, and/or one or morenetwork components may comprise some or all of the needed logic.

boot device and examine EE for software load information determine ifcurrent device load matches EE look for NE if ((current load == EE) &&(no NE present)) done else if ((current load == EE) && (NE present))upgrade device to NE else if((current load != EE) && (no NE present))upgrade device to EE else // current load != EE && NE present { if(current load == NE ) exit else upgrade device to EE and repeat theprocess }

The configuration file using upstream network logic to include softwareload information (EE) that older software loads of downstream deviceswill respond to, and further including software load information (NE)that only newer software loads of downstream devices will respond to.Sometimes the NE and/or EE information will not be included in theconfiguration file at all. The configuration file may be communicated toat least one downstream network device (e.g. during deviceinitialization). The upstream network equipment may receive a requestfrom the downstream device for the EE software load, and may communicatethe EE software load to the downstream device. Alternatively, oradditionally, the upstream network equipment may receive a request fromthe downstream device for the NE software load, and may communicate theNE software load to the downstream device.

The configuration file may be formed with management information base(MIB) entries for the EE and the NE. It may be communicated, in someembodiments, over a hybrid fiber coax (HFC) network using data overcable service interface specification (DOCSIS). In some embodiments, theEE software load and the NE software load may be communicated from aload server, the load server separate from a provisioning server thatcommunicates the configuration file to the downstream device. In otherembodiments, the load server and provisioning server may be the samedevice or collection of devices.

The downstream device (or another device, but typically the downstreamdevice itself) may receive the configuration file and check if itssoftware load matches load information (EE) of the configuration file.If the device software load does not match the EE of the configurationfile, the device may check if its software load matches new loadinformation (NE) of the configuration file. If the device software loaddoes not match the NE of the configuration file, the device may retrievevia the network, and install, a new load as described by the EE of theconfiguration file. The device may then retrieve another configurationfile and repeat the process (e.g. it may ‘double-pump’ its softwareload).

If there is no NE in the configuration file, and the device softwareload does not match the EE, the device may retrieve and install asoftware load as described by the EE. If the device software loadmatches the EE, and there is an NE entry in the configuration file, thedevice may retrieve and install a software load as described by the NE,and then it retrieving another configuration file (e.g. it may‘double-pump’ its software load).

FIG. 3 is a flow chart of an embodiment of a process to provision adevice with a software load. The process begins 302 and a modem or otherdevice receives a configuration file 304. If there is software loadinformation in the configuration file 306, a check is made 308 to see ifthe current software load of the device matches the load described inthe configuration file (the EE). If there is a match, then a furthercheck is made 310 to see if there is a new load entry NE in theconfiguration file. If not, the process concludes 314. If so, the newload is obtained and installed by the device 312. The process then doesnot conclude but rather returns the starting point 302 at which point itrepeats until such time that one of the terminating conditions applies.

FIG. 4 is a flow chart of an embodiment of a process of provisioning adevice with a software load. This process may take place in conjunctionwith the process embodiment described in FIG. 3 in the event of thecurrent load of the device does not match load information in theconfiguration file. If there is a new load entry in the configurationfile 402, a check is made 406 to determine if the current load of thedevice matches the load described in the new load entry. If it matches,the process concludes at 410. If not, an upgrade is made by the device408 to incorporate the new software load. Then, rather than concludingthe process, the process repeats, returning to the starting point 302referenced in FIG. 3. If at 402 there is not a new load entry in theconfiguration file, the device upgrades to the load information (regularload information, not new load information) in the configuration file404, and the process concludes at 410.

Following a process in accordance with the embodiments of FIGS. 3 and 4,a device may iteratively upgrade its software load. Provisioning asoftware load may include, when necessary, provisioning intermediateloads which are prerequisites to subsequent and final loads that thedevice may ultimately provision. This process may occur automatically,saving considerable cost, time, and complexity over prior techniques.

Those having skill in the art will appreciate that there are variouslogic implementations by which processes and/or systems described hereincan be effected (e.g., hardware, software, and/or firmware), and thatthe preferred vehicle will vary with the context in which the processesare deployed. For example, if an implementer determines that speed andaccuracy are paramount, the implementer may opt for a hardware and/orfirmware vehicle; alternatively, if flexibility is paramount, theimplementer may opt for a solely software implementation; or, yet againalternatively, the implementer may opt for some combination of hardware,software, and/or firmware. Hence, there are several possible vehicles bywhich the processes described herein may be effected, none of which isinherently superior to the other in that any vehicle to be utilized is achoice dependent upon the context in which the vehicle will be deployedand the specific concerns (e.g., speed, flexibility, or predictability)of the implementer, any of which may vary. Those skilled in the art willrecognize that optical aspects of implementations may involveoptically-oriented hardware, software, and or firmware.

The foregoing detailed description has set forth various embodiments ofthe devices and/or processes via the use of block diagrams, flowcharts,and/or examples. Insofar as such block diagrams, flowcharts, and/orexamples contain one or more functions and/or operations, it will beunderstood as notorious by those within the art that each functionand/or operation within such block diagrams, flowcharts, or examples canbe implemented, individually and/or collectively, by a wide range ofhardware, software, firmware, or virtually any combination thereof.Several portions of the subject matter described herein may beimplemented via Application Specific Integrated Circuits (ASICs), FieldProgrammable Gate Arrays (FPGAs), digital signal processors (DSPs), orother integrated formats. However, those skilled in the art willrecognize that some aspects of the embodiments disclosed herein, inwhole or in part, can be equivalently implemented in standard integratedcircuits, as one or more computer programs running on one or morecomputers (e.g., as one or more programs running on one or more computersystems), as one or more programs running on one or more processors(e.g., as one or more programs running on one or more microprocessors),as firmware, or as virtually any combination thereof, and that designingthe circuitry and/or writing the code for the software and/or firmwarewould be well within the skill of one of skill in the art in light ofthis disclosure. In addition, those skilled in the art will appreciatethat the mechanisms of the subject matter described herein are capableof being distributed as a program product in a variety of forms, andthat an illustrative embodiment of the subject matter described hereinapplies equally regardless of the particular type of signal bearingmedia used to actually carry out the distribution. Examples of a signalbearing media include, but are not limited to, the following: recordabletype media such as floppy disks, hard disk drives, CD ROMs, digitaltape, and computer memory; and transmission type media such as digitaland analog communication links using TDM or IP based communication links(e.g., packet links).

In a general sense, those skilled in the art will recognize that thevarious aspects described herein which can be implemented, individuallyand/or collectively, by a wide range of hardware, software, firmware, orany combination thereof can be viewed as being composed of various typesof “electrical circuitry.” Consequently, as used herein “electricalcircuitry” includes, but is not limited to, electrical circuitry havingat least one discrete electrical circuit, electrical circuitry having atleast one integrated circuit, electrical circuitry having at least oneapplication specific integrated circuit, electrical circuitry forming ageneral purpose computing device configured by a computer program (e.g.,a general purpose computer configured by a computer program which atleast partially carries out processes and/or devices described herein,or a microprocessor configured by a computer program which at leastpartially carries out processes and/or devices described herein),electrical circuitry forming a memory device (e.g., forms of randomaccess memory), and/or electrical circuitry forming a communicationsdevice (e.g., a modem, communications switch, or optical-electricalequipment).

Those skilled in the art will recognize that it is common within the artto describe devices and/or processes in the fashion set forth herein,and thereafter use standard engineering practices to integrate suchdescribed devices and/or processes into larger systems. That is, atleast a portion of the devices and/or processes described herein can beintegrated into a network processing system via a reasonable amount ofexperimentation.

The foregoing described aspects depict different components containedwithin, or connected with, different other components. It is to beunderstood that such depicted architectures are merely exemplary, andthat in fact many other architectures can be implemented which achievethe same functionality. In a conceptual sense, any arrangement ofcomponents to achieve the same functionality is effectively “associated”such that the desired functionality is achieved. Hence, any twocomponents herein combined to achieve a particular functionality can beseen as “associated with” each other such that the desired functionalityis achieved, irrespective of architectures or intermedial components.Likewise, any two components so associated can also be viewed as being“operably connected”, or “operably coupled”, to each other to achievethe desired functionality.

1. A method comprising: forming a configuration file using upstreamnetwork logic, the configuration file comprising software loadinformation (EE) that older software loads of downstream devices willrespond to, and further comprising software load information (NE) thatonly newer software loads of downstream devices will respond to;communicating the configuration file to at least one downstream networkdevice that does not comprise logic to examine and respond to the NE;receiving a request from the downstream device for the EE software load;communicating the EE software load to the downstream device, the EEsoftware load comprising logic to examine and respond to the NE;receiving a request from the downstream device for the NE software load;and communicating the NE software load to the downstream device.
 2. Themethod of claim 1, wherein the forming a configuration file usingupstream network logic further comprises: forming the configuration filewith management information base (MB) entries for the EE and the NE. 3.The method of claim 1, wherein the communicating the configuration fileto at least one downstream network device further comprises:communicating the configuration file over a hybrid fiber coax (HFC)network using data over cable service interface specification (DOCSIS).4. The method of claim 1, wherein the communicating the configurationfile to at least one downstream network device further comprises:communicating the configuration file from a provisioning server.
 5. Themethod of claim 1, wherein the communicating the EE software load to thedownstream device further comprises: communicating the EE software loadand the NE software load from a load server, the load server separatefrom a provisioning server that communicates the configuration file tothe downstream device.
 6. The method of claim 1, wherein thecommunicating the EE software load to the downstream device furthercomprises: communicating the EE software load and the NE software loadfrom a load server, the load server also a provisioning server thatcommunicates the configuration file to the downstream device.
 7. Asystem comprising: machine memory or circuits comprising upstreamnetwork logic adapted to form a configuration file comprising softwareload information (EE) that older software loads of downstream deviceswill respond to, and further comprising software load information (NE)that only newer software loads of downstream devices will respond to;machine memory or circuits comprising upstream network logic tocommunicate the configuration file to at least one downstream networkdevice that does not comprise logic to examine and respond to the NE;machine memory or circuits comprising upstream network logic to receivea request from the downstream device for the EE software load; machinememory or circuits comprising upstream network logic to communicate theEE software load to the downstream device, the EE software loadcomprising logic to examine and respond to the NE; machine memory orcircuits comprising upstream network logic to receive a request from thedownstream device for the NE software load; and upstream network logicto communicate the NE software load to the downstream device.
 8. Thesystem of claim 7, wherein forming a configuration file using upstreamnetwork logic further comprises: the upstream network logic forming theconfiguration file with management information base (MIB) entries forthe EE and the NE.
 9. The system of claim 7, wherein communicating theconfiguration file to at least one downstream network device furthercomprises: the upstream network logic communicating the configurationfile over a hybrid fiber coax (HFC) network using data over cableservice interface specification (DOCSIS).
 10. The system of claim 7,wherein communicating the configuration file to at least one downstreamnetwork device further comprises: the upstream network logiccommunicating the configuration file from a provisioning server.
 11. Thesystem of claim 7, wherein communicating the EE software load to thedownstream device further comprises: the upstream network logiccommunicating the EE software load and the NE software load from a loadserver, the load server separate from a provisioning server thatcommunicates the configuration file to the downstream device.
 12. Thesystem of claim 7, wherein communicating the EE software load to thedownstream device further comprises: the upstream network logiccommunicating the EE software load and the NE software load from a loadserver, the load server also a provisioning server that communicates theconfiguration file to the downstream device.